It is common to have applications corrupted or hijacked by viruses or to have Trojans run that gather passwords or other critical data and send them outside of the supposedly protected or secure computing environments.
Even hardware-enhanced security systems can be compromised in some situations through unexpected inputs from outside agents, in some cases allowing such agents to view decrypted data in the clear. For example, an unexpected flaw in application code can lead to a buffer overflow attack where foreign code is introduced through normal user input. Such foreign code then executes at the same permission level as the original application code and can easily access decrypted data in memory. Some attacks are known that use existing application code in unintended ways to execute system calls and copy data for the purposes of an attacker, without introducing new code into a process.
Furthermore, it is straightforward in some situations to modify an application program that is stored on a disk drive or other program storage area to allow access to its internal operations and its internal unencrypted data during that programs execution.
The standard way to add security policies to existing applications or system modules is to change their source code, re-compile them and then re-deploy the software. In large interdependent systems this process can take years. The ideal deployment strategy would be to deploy new security systems and policies at a customer site by modifying the existing deployed code in some way. Deployed code exists on disk storage and is loaded into a computer memory when it is to be executed. In either case, analyzing the existing code in order to add security policies is very difficult. It is even difficult to distinguish code from data within existing binaries, particularly on Intel architectures, due to the variable length instructions and the lack of information about branch targets.